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In  1995  is  door  bet  US  Defense  Modeling  and  Simulation  Office  (DMSO)  het 
startschot  gegeven  voor  de  ontwikkeling  van  een  generieke  architectuur,  de  High 
Level  Architecture  (HLA),  met  als  doel  het  bevorderen  van  interoperabiliteit 
tussen  simulaties  en  van  hergebruik  van  simulaties.  Deze  architectuur  zal  de  basis 
gaan  vormen  voor  alle  simulatie  activiteiten  binnen  de  US  DoD.  De  DIS  IEEE 
1278  standaarden,  die  de  afgelopen  jaren  als  basis  hebben  gediend  voor  gedistri¬ 
bueerde  interactieve  simulatie,  zullen  gaan  wegebben  en  worden  vervangen  door 
de  nieuwe  HLA  standaarden.  De  HLA  vioeit  voort  uit  de  ervaringen  die  opgedaan 
zijn  met  bestaande  standaarden  als  DIS  en  ALSP.  Voor  toekomstige  simulatie 
systemen  is  het  zaak  om  de  blik  op  HLA  te  richten,  o.a.  om  internationale  interope¬ 
rabiliteit  op  lange  termijn  te  waarborgen. 

De  Run-Time  Infrastructure  (RTI)  is  de  basis  communicatie  laag  van  de  HLA  die 
uitwisseling  van  informatie  tussen  simulatie  applicaties  verzorgt  op  basis  van  een 
gestandaardiseerde  interface  specificatie.  Het  data  distributie  mechanisme  van  de 
RTI  biedt  de  gebruiker  diverse  vormen  van  informatie  filtering  om  de  communica¬ 
tie  van  irrelevante  data  te  voorkomen  en  de  network  performance  te  maximalise- 
ren.  Een  aantal  implementaties  van  de  RTI  is  reeds  gerealiseerd,  waaronder  de 
DMSO  RTI  versie  1.0  die  vrij  verkrijgbaar  is.  Zowel  qua  functionaliteit  als  per¬ 
formance  is  deze  versie  een  behoorlijk  volwassen  RTI  implementatie,  maar  aange- 
zien  de  source  code  niet  vrij  gegeven  is  en  slechts  een  beperkt  aantal  computer 
platformen  ondersteund  worden,  heeft  het  gebruik  van  de  DMSO  RTI  zijn  beper- 
kingen. 


HLA  applicaties  wisselen  informatie  uit  in  de  vorm  van  objects  en  interactions. 
Een  object  representeert  b.v.  een  voorwerp  in  de  virtuele  omgeving.  Een  interacti¬ 
on  is  een  unieke,  tijdgebonden  gebeurtenis.  Aangezien  de  HLA  standaarden  geen 
uitspraak  doen  over  de  semantiek  van  de  uit  te  wisselen  informatie,  wordt  deze 
vastgelegd  in  een  Federation  Object  Model  (FOM).  De  FOM  is  een  ‘contract’ 
tussen  de  deelnemende  applicaties  met  een  specificatie  van  de  uit  te  wisselen 
informatie.  Omdat  federates  binnen  een  toepassingsdomein  vaak  dezelfde  soort 
informatie  uitwisselen,  is  het  concept  Reference  FOM  geintroduceerd.  Een  Refe¬ 
rence  FOM  beschrijft  een  generieke  data  structuur  voor  een  bepaald  applicatie- 
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domein.  De  FOM  ontwikkelaar  kan  de  Reference  FOM  verfijnen  voor  zijn  speci- 
fieke  eisen.  De  Real-time  PlatformAevel  Reference  Federation  Object  Model 
(RPR-FOM)  is  een  voorgestelde  data  structuur  die  de  inhoud  van  de  reeds  be- 
staande  DIS  PDU’s  beschrijft  in  de  vorm  van  een  object  en  interaction  class  hie¬ 
rarchic.  De  RPR-FOM  zal  een  belangrijk  hulpmiddel  zijn  bij  de  migratie  van  DIS 
naar  HLA  voor  real-time,  human-in-the-loop  simulaties  van  platform  entiteiten 
(zoals  tanks  en  vliegtuigen). 

Het  Advanced  Simulation  Framework  (ASF)  vormt  de  basis  voor  de  ontwikkeling 
van  gedistribueerde  simulatie  applicaties  binnen  de  TNO-FEL  Electronic  Battles- 
pace  Facility  (EBF).  De  EBF  biedt  een  infrastructuur  voor  onderzoek  naar  en 
toepassing  van  gedistribueerde  interactieve  simulatie  technologieen.  Het  ASF 
schermt  de  applicatie  ontwikkelaar  af  van  standaarden  zoals  DIS  en  HLA  d.m.v. 
een  generiek  interface.  Het  ASF  vormt  als  het  ware  een  laag  {"middleware  layer') 
tussen  de  simulatie  applicatie  en  de  onderliggende  gedistribueerde  simulatie  stan¬ 
daarden.  Deze  opzet  vergemakkelijkt  migraties  naar  nieuwe  standaarden  zonder 
ingrijpende  aanpassingen  van  de  simulatie  applicatie  zelf. 

Dit  rapport  is  een  tussenrapportage  en  beschrijft  de  recente  ontwikkelingen  op  het 
gebied  van  de  HLA,  RTI  en  RPR-FOM,  Tevens  beschrijven  we  de  integratie  van 
deze  standaarden  en  technologieen  in  het  door  TNO-FEL  ontwikkelde  ASF.  De 
belangrijkste  conclusie  van  het  onderzoek  is  dat  de  HLA  ontwikkeling  op  voile 
toeren  draait  en  in  de  US  als  basis  voor  alle  simulatie-  en  modelleer-activiteiten 
wordt  geaccepteerd,  Het  onderzoek  naar  gedistribueerde  simulatie  zal  worden 
voortgezet  met  o.a.  een  performance  analyse  van  de  RTI  en  de  migratie  van  een 
DIS  simulator  prototype  naar  HLA. 
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1.  Introductie 


Dit  rapport  is  een  (tussen)rapportage  van  het  project  'Kennisonderhoud  DIS/HLA' 
(A95KL841)  en  een  vervolg  op  eerdere  rapportages,  presentaties  en  demon straties 
over  het  onderwerp  Advanced  Distributed  Simulation  Technology. 

Dit  rapport  is  gericht  op  de  ontwikkelingen  van  de  High  Level  Architecture  (HLA), 
met  name  op  het  technische  vlak,  gedurende  het  afgelopen  jaar.  Het  HLA  initiatief 
is  medio  1995  gestart  door  het  US  Defense  Modeling  and  Simulation  Office 
(DMSO)  en  behelst  de  ontwikkeling  van  een  generieke  architectuur  voor  alle 
modelleer-  en  simulatie-activiteiten.  HLA  vloeit  voort  uit  de  ervaringen  opgedaan 
met  bestaande  standaarden  als  DIS  en  ALSP.  In  de  Simulation  Interoperability 
Workshop  (SIW)  in  Orlando,  Florida  worden  twee  keer  per  jaar  de  bevindingen  en 
nieuwe  ontwikkelingen  rond  HLA  gepresenteerd.  Deze  workshop,  de  opvolger  van 
de  DIS  workshop,  wordt  gehouden  onder  auspicien  van  de  Simulation  Interopera¬ 
bility  Standards  Organization  (SISO). 

Hoofdstuk  2  geeft  een  beknopte  beschrijving  van  de  HLA  standaarden  en  zijn 
componenten.  In  hoofdstuk  3  presenteren  we  de  huidige  stand  van  zaken  rond  de 
Run-Time  Infrastructure  (RTI),  het  ‘hart’  van  HLA  dat  de  communicatie  tussen 
simulatie  applicaties  tot  stand  brengt.  In  hoofdstuk  4  schetsen  we  de  activiteiten 
rond  de  migratie  van  de  DIS  standaard  naar  HLA.  Het  Advanced  Simulation  Fra¬ 
mework  (ASF)  is  een  TNO-FEL  software  architectuur  voor  de  ontwikkeling  van 
gedistribueerde  simulatie  applicaties.  De  gerealiseerde  koppeling  tussen  het  ASF 
en  de  HLA  RTI  wordt  beschreven  in  hoofdstuk  5.  In  hoofdstuk  6  trekken  we  een 
aantal  conclusies  en  Bijlage  A  bevat  de  volledige  Real-time  Platform  Reference 
FOM  (RPR-FOM),  versie  0. 1 .7. 
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2.  High  Level  Architecture 

2.1  Inleiding 

Het  doel  van  de  HLA  is  tweeledig:  interoperabiliteit  tussen  simulatie  modellen  en 
hergehniik  van  simulatie  modellen. 

De  HLA  standaard  omvat  drie  onderdelen:  de  HLA  Rules,  de  HLA  Interface 
Specification  en  de  Object  Model  Templates.  Dit  rapport  zal  deze  onderdelen 
slechts  beknopt  beschrijven  aangezien  dit  in  de  vorige  rapportage  ([FEL96A273]) 
reeds  uitvoerig  gedaan  is  (m.u.v.  data  distribution  management).  Alvorens  verder 
in  te  gaan  op  de  onderdelen  van  de  HLA  standaard,  omschrijven  we  eerst  een 
aantal  termen: 

Federate 

HLA-compliant  applicatie  b.v.  een  simulator,  data  logger,  semi-automatic  forces 
generator,  simulation  management  tool  of  presentatie  gereedschap  zoals  3D- 
Stealth  of  Audio  server. 

Federation 

Verzameling  van  federates  die  een  applicatie-domein  vertegen- 

woordigen.  Deze  federates  moeten  zich  houden  aan  de  Federation  Object  Model 
(FOM)  die  voor  deze  federation  is  opgesteld. 

Federation  Object  Model  (FOM) 

Contract  tussen  federates  die  alle  toegestane  informatie  uitwisseling  tussen  de 
federates  vastlegt.  De  FOM  is  samengesteld  uit  delen  van  de  SOM’s  van  de  parti- 
ciperende  federates. 

Simulation  Object  Model  (SOM) 

De  SOM  specificeert  de  ‘capabilities’  en  ‘requirements’  van  een  individueie 
federate,  d.w.z.  welke  data  zal  de  federate  genereren  en  welke  data  heeft  de  fede¬ 
rate  nodig. 


Object 

Entiteit  met  unieke  identificatie  en  eigen  status  binnen  de  federation.  De  status  van 
een  object  wordt  bepaald  door  de  huidige  waarden  van  zijn  attributes.  Objecten 
worden  formeel  vastgelegd  in  de  SOM  en  FOM. 

Object  Model  Template  (OMT) 

Gestandaardiseerde  formaten,  in  de  vorm  van  tabellen,  voor  het  beschrijven  van  de 
SOM  en  de  FOM. 
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Attribute 

Karakteristieke  eigenschap  van  een  object,  b.v.  positie  of  snelheid.  De  attribute 
waarden  worden  door  de  federates  uitgewisseld  conform  de  FOM. 

Interaction 

Unieke,  tijdgebonden  gebeurtenis  (event)  in  de  federation  die  uitgewisseld  wordt 
door  de  federates  conform  de  FOM.  De  interaction  wordt  beschreven  aan  de  hand 
van  een  aantal  parameter  waarden. 

Federation  execution 

Het  verloop  van  de  federation  oefening.  Zolang  minstens  1  federate  actief  is, 
bestaat  de  federation  execution. 


2.2  HLA  Rules 

De  Rules  vormen  een  verzameling  van  technische  principes  en  afspraken  waaraan 
HLA  deelnemers  zich  moeten  houden  om  HLA-compliant  te  zijn.  De  Rules  bestaan 
uit  5  federation  rules,  regels  die  slaan  op  de  verzameling  van  applicaties  die  tot 
een  bepaald  simulatie  applicatie-domein  behoren,  en  5  federate  rules,  regels  die  op 
de  simulatie  applicaties  zelf  slaan.  Twee  voorbeelden  van  Rules  zijn: 

Federation  Rule  1 : 

Hike  federation  moet  een  Federation  Object  Model  (FOM)  hebben,  conform  de 
gestandaardiseerde  formaten  van  de  Object  Model  Templates  (OMT). 

Federate  Rule  1 : 

Hike  federate  moet  een  Simulation  Object  Model  (SOM)  hebben,  conform  de 
gestandaardiseerde  formaten  van  de  Object  Model  Templates  (OMT). 


2.3  HLA  Object  Model  Templates 

De  Object  Model  Templates  zijn  gestandaardiseerde  formaten  die  gebruikt  worden 
om  de  ‘capabilities’  en  ‘requirements’  van  alle  deelnemende  simulatie  modellen  te 
specificeren.  De  volgende  vijf  templates  worden  gebruikt  om  de  SOM  en  de  FOM 
op  te  stellen: 

•  Object  Class  Structure  Table 

Beschrijving  van  de  object  class-subclass  relaties. 

•  Interaction  Class  Structure  Table 

Beschrijving  van  de  interaction  class-subclass  relaties. 
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•  Attribute  Table 

Specificatie  van  alle  object  attributen. 

•  Parameter  Table 

Specificatie  van  alle  interaction  parameters. 

•  FOM/SOM  Lexicon 

Definitie  van  alle  termen  in  bovengenoemde  tabellen. 

Bijlage  A  bevat  een  formele  beschrijving  van  de  RPR-FOM  0.1.7  op  basis  van  de 
HLA  Object  Model  Templates. 


2.4  HLA  Interface  Specification 

De  Interface  Specification  is  een  formele,  functionele  beschrijving  van  het  interfa¬ 
ce  tussen  enerzijds  de  HLA  applicatie  en  anderzijds  de  Run-Time  Infrastructure 
(RTI).  RTI  versie  1.0  van  DMSO  ondersteunt  Interface  Specification  1.1.  Deze 
specificatie  biedt  functies  voor  de  volgende  RTI  services: 

1 .  Federation  Management 

Functies  voor  het  creeren,  verwijderen,  onderbreken  en  hervatten  van  federati¬ 
on  executions. 

2.  Declaration  Management  (DM) 

Een  HLA  federate  deelt  de  federation  mede  welke  type  object-  en  interaction- 
informatie  hij  tijdens  de  oefening  gaat  produceren  d.m.v.  publication.  Tevens 
abonneert  elke  federate  zich  op  informatie  die  voor  hem  relevant  is  d.m.v.  sub¬ 
scription.  Zo  zal  de  RTI  alleen  relevante  informatie  doorgeven  aan  de  federate 
en  irrelevante  informatie  negeren.  Zowel  publications  als  subscriptions  kunnen 
tijdens  de  oefening  dynamisch  gewijzigd  vvorden.  Het  doel  van  DM  is  om  de 
benodigde  communicatie  bandbreedte  te  beperken,  door  alleen  relevante  data 
te  distribueren. 

3.  Object  Management 

Functies  voor  het  uitwisselen  van  object-  en  interaction  data.  De  RTI  bewaart 
object  attributes  en  interaction  parameters  niet  intern,  maar  fungeert  als  com¬ 
municatie  mechanisme  tussen  de  HLA  federates.  De  RTI  bewaart  wel  sommi- 
ge  object  informatie  voor  de  interne  boekhouding,  zoals  object  ID’s  en  ow¬ 
nership  data. 

4.  Ownership  Management 

Elk  object  wordt  in  principe  beheerd  door  de  federate  die  het  object  gei'nstanti- 
eerd  heeft.  Het  is  echter  mogelijk  de  ‘ownership’  van  object  attributen  over  te 
dragen  aan  andere  federates,  of  ‘ownership’  van  bepaalde  attributen  aan  te 
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vragen.  Een  praktisch  voorbeeld  hiervan  is  een  tanksimulator  die  uitgerust 
wordt  met  een  nieuw,  geavanceerder  bewegingsmodel.  Dit  bewegingsmodel  is 
een  aparte  federate  die  eigenaar  wordt  van  de  positie-attribute  van  het  tank 
object  en  zo  de  actuele  positie  kan  specificeren. 

5.  Time  Management 

Aangezien  HLA  een  breed  scala  van  toepassingsgebieden  moet  ondersteunen, 
zowel  event-driven  (b.v.  ALSP)  als  time-driven  (b.v.  DIS),  biedt  HLA  meerde- 
re  time  management  mechanismen.  Deze  zijn  gebaseerd  op  twee  orthogonale 
factoren:  ''time  regulated"  en  "time  constrained" .  Time  regulated  wil  zeggen 
dat  time  advances  in  de  federation  centraal  gecoordineerd  zijn.  De  federate 
bepaalt  dus  mede  wat  de  simulatie  tijd  van  de  hele  federation  is.  Time  cons¬ 
trained,  ook  wel  paced  genoemd,  wil  zeggen  dat  de  simulatie  tijd  van  een  fede¬ 
rate  gerelateerd  is  aan  de  muurklok  (b.v.  voor  human-in-the-loop  simulatie), 
terwijl  unconstrained  federates  zelf  hun  voortgang  bepalen  (b.v.  as-fast-as- 
possible).  In  het  geval  van  een  time  constrained  federate  zal  de  RTI  alleen  be- 
richten  aan  de  federate  doorgeven  met  een  timestamp  kleiner  (dus  ouder)  dan 
de  federate  time.  Time  regulating  zegt  dus  iets  over  de  voortgang  van  de  fede¬ 
ration  time,  terwijl  time  constrained  iets  zegt  over  de  voortgang  van  de  fede¬ 
rate  time. 

6.  Data  Distribution  Management  (DDM) 

Behalve  filtering  op  informatie  type  zoals  beschreven  in  Declaration  Manage¬ 
ment,  biedt  de  Interface  Specification  ook  de  mogelijkheid  te  filteren  op  object 
attribuiit  waarden.  Aangezien  DDM  niet  in  Interface  Specification  I.O  zat  en 
niet  in  de  vorige  rapportage  is  beschreven,  gaan  we  er  hier  wat  dieper  op  in. 


2.5  Data  Distribution  Management 

Interface  Specification  1.1  biedt  een  set  van  services  om  efficiente  data  distributie 
binnen  de  federation  te  realiseren  teneinde  de  benodigde  communicatie  band- 
breedte  te  beperken.  Deze  data  distributie  is  gebaseerd  op  het  concept  van  routing 
spaces.  Een  routing  space  is  een  abstrakt,  logisch  multi-dimensionaal  coordinaten 
systeem  in  welke  de  federates  hun  interesses  beschrijven,  voor  het  ontvangen  of 
voor  het  zenden  van  bepaalde  informatie.  Binnen  de  federation  kunnen  een  aantal 
routing  spaces  gedefinieerd  worden  met  op  de  assen  van  het  coordinaten  systeem 
de  variabelen.  Elke  routing  space  is  uniek  identificeerbaar. 

Zoals  eerder  vermeld  kan  m.b.v.  Declaration  Management  geselecteerd  worden  op 
informatie  type.  Routing  spaces  worden  gebruikt  om  de  distributie  condities  te 
specificeren  voor  het  zenden  of  ontvangen  van  informatie  (objects  en  interaction 
data)  op  basis  van  object  attribute  waarden  en  interaction  parameter  waarden. 
Elke  federate  bepaalt  welke  routing  spaces  voor  hem  van  belang  zijn  en  definieert 
regions,  logische  gebieden  van  de  routing  space  die  voor  de  federate  interessant 
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zijn,  door  voor  elke  dimensie  begrenzingen  {extents)  op  te  geven.  Door  een  sub¬ 
scription  region  te  koppelen  aan  een  object  instantie  of  interaction  class  geeft  de 
federate  aan  dat  hij  alleen  informatie  wil  ontvangen  die  voldoet  aan  de  object 
attribute  grenzen  en  interaction  parameter  grenzen  zoals  in  de  region  gedefinieerd. 
Een  update  region  geeft  aan  dat  de  federate  informatie  zal  genereren  binnen  de 
gedefinieerde  begrenzingen.  Regions  kunnen  dynamisch  worden  aangepast  en 
koppelingen  met  objecten/interactions  kunnen  worden  veranderd.  De  RTI  zal  data 
distribueren  op  basis  van  overlapping  van  subscription-  en  update  regions.  Als  er 
geen  overlap  is,  betekent  het  dat  er  geen  interesse  is  in  de  gegenereerde  informatie, 
m.a.w.  de  data  hoeft  niet  gedistribueerd  te  worden.  Ook  object  attributen  die  zelf 
niet  uitgewisseld  worden  kunnen  dienst  doen  als  routing  space  variabelen.  Elke 
federate  kan  meerdere  subscription-  en  update  regions  creeren.  Een  object  attribute 
mag  in  maximaal  1  routing  space  voor  komen,  zodat  geen  conflicterende  situaties 
kunnen  onstaan  met  verschillende  extents  voor  dezelfde  attribute  in  meerdere 
routing  spaces. 

Figuur  1  toont  een  voorbeeld  van  DDM  met  1  update  region  (Ul)  en  2  subscription 
regions  (SI  en  S2),  Aangezien  Ul  en  SI  deels  overlappen  zullen  attributen  en 
interactions  die  met  Ul  geassocieerd  ziJn  verstuurd  worden  naar  de  federate  die 
subscription  region  S I  gecreeerd  heeft.  Omdat  er  geen  overlap  is  tussen  Ul  en  S2 
zal  de  federate  die  S2  gecreeerd  heeft  geen  data  ontvangen. 


DDM  filtering  op  basis  van  routing  spaces  en  Declaration  Management  filtering  op 
basis  van  subscriptions  en  publications  kunnen  elkaar  tegenspreken.  In  dat  geval 
hebben  de  DDM  filter  criteria  de  hoogste  prioriteit.  Er  wordt  nog  door  de  RTI 
ontwikkelaars  onderzoek  gedaan  naar  Data  Distribution  Management  en  de  relatie 
met  Time  Management.  Daarom  doet  de  Interface  Specification  1 . 1  nog  geen 
uitspraak  over  het  precieze  tijdstip  dat  een  DDM  service  effect  zal  hebben. 
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3.  Run-Time  Infrastructure 

3.1  Inleiding 

De  Run-Time  Infrastructure  (RTI)  is  de  general-purpose  software  module  die  de 
services,  zoals  vastgelegd  in  de  HLA  Interface  Specification,  implementeert.  De 
RTI  kan  men  vergelijken  met  een  gedistribueerd  operating  system  dat  de  applicatie 
bepaalde  diensten  biedt  om  informatie  uit  te  wisselen  met  andere  applicaties 
(federates). 

De  RTI  fungeert  als  een  doorgeefluik  voor  de  uitwisseling  van  informatie  tussen 
federates.  De  RTI  bewaart  zelf  geen  object  attributes,  dit  is  de  taak  van  de  federate. 
Het  data  distributie  mechanisme  van  de  RTI  biedt  de  gebruiker  diverse  vormen  van 
informatie  filtering  om  de  communicatie  van  irrelevante  data  te  voorkomen  en  de 
netwerk  performance  te  maximaliseren. 


3.2  Implementaties 

De  eerste  versie  van  de  RTI  (F.O)  was  een  prototype  gebaseerd  op  CORE  A  1 .0 
[COREA].  Vervolgens  is  er  ook  een  prototype  in  C++  gebouwd.  Deze  prototypes 
bevatten  een  subset  van  de  Interface  Specification  1.0  en  richtten  zich  voorname- 
lijk  op  volledigheid  van  functionaliteit  en  nog  niet  op  een  maximale  performance 
van  de  RTI, 

De  ontwikkeling  van  een  RTI  implementatie  is  nu  onderverdeeld  in  twee  fases.  De 
eerste  fase  richt  zich  op  de  ontwikkeling  van  RTI  1.0  om  de  technische  haalbaar- 
heid  van  het  RTI  concept  aan  te  tonen.  Deze  RTI  implementatie  wordt  gesponsord 
door  DMSO  en  is  als  library  vrij  verkrijgbaar  op  het  internet.  De  source  code  van 
de  RTI  is  niet  vrij  gegeven.  RTI  1.0  implementeert  alle  HLA  Interface  Specificati¬ 
on  1.1  services  behalve  Data  Distribution  Management  (DDM).  Implementatie  van 
Interface  Specification  1 .2  is  stop  gezet  en  de  volgende  RTI  implementatie,  rond 
maart  1998,  zal  alle  Interface  Specification  1.3  services  ondersteunen.  De  tweede 
fase  behelst  de  ontwikkeling  van  RTI  2.0  door  de  industrie. 

De  RTI  1.0  is  voor  de  volgende  computer  platforms  verkrijgbaar: 

Sun/Solaris  2.x,  SGI/Irix  6.x,  Windows  NT,  lEM  AIX  4.1.5  en  HP-UX  El 0.20. 

We  hebben  geexperimenteerd  met  RTI  versie  1.0.2  met  een  C++  interface.  Eehal- 
ve  C++  is  er  ook  een  Ada  en  Java  versie.  De  Ada  RTI  versie  is  een  schil  om  de 
C++  implementatie,  de  Java  versie  is  geheel  in  Java  geschreven.  De  distributie 
software  van  de  C++  versie  beslaat  ca.  55  Mbyte  inclusief  demo  programma’s.  Per 
federate  is  ca.  10  tot  15  Mbyte  geheugen  nodig  voor  de  RTI  federate  library,  De 
HLA  federates  draaiden  op  een  Sun  SPARCserver-1000  onder  Solaris  2.5  [RTI]. 
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RTI  1.0  is  reeds  door  de  HLA  community  uitvoerig  getest  met  grote  varieteit  aan 
applicaties.  Een  federation  met  500  objecten,  gedistribueerd  over  8  federates  met 
ca.  200  updates/sec  per  federate  is  al  met  succes  gedemonstreerd  op  basis  van  Ultra 
Sparc  2  processors  in  een  LAN.  T.o.v.  de  RTI  F.O  is  de  performance  enorm  verbe- 
terd.  Over  update  latencies  is  nog  niet  veel  bekend. 


3.3  RTI  1.0  Architectuur 

Figuur  2  geeft  schematisch  de  componenten  van  de  architectuur  weer. 


Figuur2  RTI  1 .0  Architectuur 

RTI  1.0  is  een  gedistribueerd  systeem  dat  uit  3  hoofdcomponenten  bestaat: 

•  RTI  Executive  (rtiexec) 

Globaal  proces  dat  de  creatie  en  destructie  van  federation  executions  beheert. 
De  RTI  Executive  is  het  eerste  aanspreekpunt  voor  een  initialiserende  federate 
en  voorziet  de  federate  met  een  handle  naar  de  federation  execution.  Via  deze 
handle  kan  de  federate  met  het  fedex  process  communiceren.  De  RTI  Executive 
kent  ook  een  multicast  group  toe  aan  een  federation  execution  voor  de  commu- 
nicatie  van  best-effort  data  op  basis  van  unreliable  UDP/IP. 

•  Federation  Executive  (fedex) 

Globaal  proces  per  federation  execution  dat  ‘joining’  en  ‘resigning’  van  fede¬ 
rates  afhandelt.  De  Federation  Executive  fungeert  als  een  ‘information  explo¬ 
der’  voor  de  communicatie  van  rehable  data  op  basis  van  TCP/IP  (Figuur  3) 
door  de  data  van  1  ontvanger  naar  meerdere  ontvangers  te  distribueren.  Dit  glo- 
bale  proces  wordt  automatisch  opgestart  door  de  eerste  federate  die  een  federa¬ 
tion  creeert.  Het  proces  termineert  als  alle  federates  de  federation  hebben  ver- 
laten. 
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•  RTI  federate  library 

Deze  wordt  meegelinkt  met  de  federate  code  en  bevat  de  implementatie  van  de 
interface  naar  de  HLA  1.1  services,  De  federate  activeert  de  HLA  services 
door  calls  in  deze  library. 


Figuiir  3  Reliable  data  comrnunicatie 

Het  interface  tussen  de  federate  en  de  RTI  bestaat  uit  twee  classes:  de  RTIambas- 
sador  en  de  FedAmbassador.  Comrnunicatie  tussen  de  federate  en  RTI  is  bi- 
directioneel:  data  van  federate  naar  RTI  en  data  van  RTI  naar  federate.  De  RTIam- 
bassador  class  bevat  alle  functionaliteit  die  de  federate  nodig  heeft  om  met  de  RTI 
te  communiceren  b.v.  voor  het  verzenden  van  object  attribute  updates.  De  FedAm¬ 
bassador  class  bevat  een  interface  voor  de  RTI  om  met  de  federate  te  communice¬ 
ren  b.v.  voor  het  doorgeven  van  binnenkomende,  door  andere  federates  gegene- 
reerde,  attribute  updates.  Het  is  aan  de  federate  om  deze  class  methods  verder  te 
implementeren  en  uit  te  breiden  met  specifieke  functionaliteit  voor  de  verdere 
afhandeling.  De  federate  is  verplicht  dit  te  doen,  aangezien  de  compiler  foutmel- 
dingen  zal  genereren  indien  bepaalde  FederateAmbassador  class  methods  niet 
geimplementeerd  zijn. 

3.3.1  Data  representatie 

Comrnunicatie  tussen  heterogene  computer  platformen  (Sun,  SGI,  PC)  vereist 
duidelijke  afspraken  over  de  netwerk  representatie  van  de  uit  te  wisselen  data.  Om 
de  computer  platform-specifieke  data  representatie  om  te  kunnen  zetten  naar  de 
platform-onafhankelijke  netwerk  representatie  (en  vice  versa),  moet  men  het 
datatype  weten.  Aangezien  de  RTI  1.0  niet  de  datatypes  kent  van  object  attributen 
en  interaction  parameters,  is  deze  conversie  de  verantwoordelijkheid  van  de  fede¬ 
rate  zelf. 


3.3.2  Federation  Execution  Data  (FED) 

De  RTI  1.0  heeft  twee  configuratie  files  nodig  om  federation  executions  te  kunnen 
uitvoeren:  dt  federation  execution  data  (FED)  file  en  de  run-time  initialization 
data  (RID)  file.  De  FED  file  (Figuur  4)  bevat  de  data  structuur  van  de  object 
classes  en  interaction  classes,  zoals  in  de  FOM  afgesproken.  Ook  is  aangegeven 
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welke  transport  mechanisme  (‘best-effort’  of  ‘reliable’)  en  welke  tijd-sorteer 
(‘time-ordering’)  mechanisme  (‘receive-order’  of  ‘timestamped-order’)  er  per 
object  class  attribute  of  interaction  class  gebruikt  gaat  worden.  Het  sorteer  mecha¬ 
nisme  geeft  aan  of  de  RTI  de  informatie  gesorteerd  op  timestamp  doorgeeft  aan  de 
federate  of  dat  de  informatie  in  volgorde  van  ontvangst  wordt  doorgegeven.  De 
FED  file  beschrijft  niet  de  datatypes  van  de  object  attributen  en  interaction  para¬ 
meters. 


;;  Comments  are  any  text  after  a  semicolon. 

; ;  basic  syntax  example 

;;  possible  <transportation>  =  FED_RELIA3LE,  FED_BEST_EFFORT 
!  / 

; ;  possible  <ordering>  =  FED_RECEIVE,  FED_TIMESTAMP 

( fed 

;;  object,  class,  and  attribute  definitions  follow 
(objects 

(class  <name> 

(attribute  <name>  <transportation>  <ordering>) 

(attribute  <name>  <transportation>  <ordering>) 

; ;  any  Other  attributes  must  come  before  subclasses  for  same  level 
(class  <name> 

(attribute  <name>  <transportation>  <ordering>} 

(attribute  <name>  <transportation>  <ordering>) 

) 

) 

) 

;;  interactions,  class,  and  parameter  definitions  follow 
( interactions 

(class  <name>  <transportation>  <ordering> 

(parameter  <name>} 

(parameter  <name>) 

; ;  any  Other  parameters  must  come  before  subclasses  for  same  level 
(class  <name>  <transportation>  <ordering> 

(parameter  <name>) 

(parameter  <name>) 

} 

} 

) 

)  ;  end  of  fed 


Figiiur  4  Federation  Execution  Data  ( FED)  file  formaat 


3.3.3  Run-time  Initialization  Data  (RID) 

De  run-time  initialization  data  (RID)  file  (Figuur  5)  bevat  allerlei  systeem  infor¬ 
matie  zoals  b.v.  op  welke  computer  de  RTI  Executive  draait  en  op  welk  portnum- 
mer  de  RTI  Executive  wacht  op  federate  connecties.  Ook  specificeert  deze  confi- 
guratie  file  o.a.  het  maximale  aantal  objecten  per  federate. 
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############################################################################ 

#  FILE  :  RTI.rid 

#  PURPOSE:  This  file  is  the  main  configuration  file  for  the  RTI. 
############################################################################ 

###########################################"################################ 

#  VARIABLE:  BEST_EFFORT_PORT 

#  UNITS  :  Positive  integer 

#  PURPOSE  :  To  specify  the  port  number  on  which  best-effort  multicast 

#  addressing  will  be  attempted. 

############################################################################ 
BEST_EFFORT_PORT  18134 

############################################################################ 

#  VARIABLE:  MAX_OBJECTS_PER_FEDERATE 

#  UNITS  :  Positive  integer 

#  PURPOSE  :  To  specify  the  maximum  number  of  objects  a  federate  may  know 
about . 

############################################################################ 
MAX_OBJECTS_PER_FEDERATE  100000 

############################# ##################1^####### ######## ############# 

#  VARIABLE:  RTI_EXEC_HOST 

#  UNITS  :  Character  string 

#  PURPOSE  :  To  specify  the  hostname  of  machine  on  which  the  RTI  Executive 

#  process  is  executing. 

RTI_EXEC_HOST  sOOsnl 

#  VARIABLE:  RTI_EXEC_PORT 

#  UNITS  :  Positive  integer 

#  PURPOSE  :  To  specify  the  port  number  on  which  the  RTI  Executive  process  is 

#  listening  for  connections. 

RTI_EXEC_PORT  3800 


Figiiiir  5  RTI.rid  voorbeeld  file 


3.3.4  Management  Object  Model 

Behalve  de  uitwisseling  van  simulatie  data  tussen  HLA  federates,  wisselen  de 
federates  ook  data  uit  ter  ondersteuning  van  federation  management  en  monito¬ 
ring.  Deze  data  bevat  o.a.  gegevens  over  de  identiteit  van  de  federate,  RTI  settings, 
RTI  versie  en  interne  queue  grootten.  Uitwisseling  van  deze  meta-data  is  nodig 
voor  de  interne  boekhouding  van  de  RTI.  Tevens  heeft  de  gebruiker  toegang  tot 
deze  informatie.  De  structuur  van  deze  informatie  wordt  beschreven  in  de  Mana¬ 
gement  Object  Model  (MOM).  Deze  structuur  is  qua  formaat  identiek  aan  de 
beschrijving  van  simulatie  data.  De  MOM  informatie  die  de  RTI  nodig  heeft  om  te 
kunnen  functioneren  zal  gestandaardiseerd  worden.  De  federate  kan  zelf  de  MOM 
uitbreiden  met  federation-specifieke  informatie. 
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3.4  Multicasting 

Multicasting  is  het  mechanisme  waarbij  data  van  1  zender  naar  meerdere  ontvan- 
gers  wordt  verstuurd.  Op  dit  moment  is  multicasting  alleen  mogelijk  binnen  een 
LAN  omgeving,  omdat  er  nog  geen  gestandaardiseerde  multicast  routing  protocols 
zijn  voor  multicasting  op  een  WAN,  zoals  het  internet.  Routers  weten  nu  niet  hoe 
ze  met  de  multicast  packets  om  moeten  gaan.  Alhoewel  er  al  meerdere  voorstellen 
voor  routing  protocols  zijn  gedaan,  laat  een  standaardisatie  nog  op  zich  wachten. 
Een  multicast  group  wordt  binnen  het  IP  protocol  gerepresenteerd  door  een  Class 
D  adres.  Het  aantal  mogelijke  multicast  groups  is  beperkt,  omdat  de  IP  adressen  in 
een  vastgelegd  interval  moeten  liggen.  Er  wordt  een  onderscheid  gemaakt  tussen 
permanente  {'permanent')  en  tijdelijke  {'temporary')  multicast  group  adressen. 
Thans  is  multicasting  gebaseerd  op  'best-effort'  communicatie,  maar  er  is  ook  een 
grote  behoefte  aan  'reliable  multicasting',  waarbij  de  ontvangst  van  de  data  gega- 
randeerd  is.  Vanuit  de  HLA  gemeenschap  wordt  er  nauw  gelet  op  de  ontwikkelin- 
gen  op  het  gebied  van  multicasting,  omdat  dit  de  basis  vormt  voor  een  goed  functi- 
onerend  data  distributie  mechanisme  binnen  HLA. 
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4.  Real-time  Platform-level  Reference  FOM 

4.1  Inleiding 

Voorafgaand  aan  de  ontwikkeling  van  de  High  Level  Architecture  was  het  Distri¬ 
buted  Interactive  Simulation  (DIS)  protocol  het  meest  gebruikte  mechanisme  om 
heterogene,  real-time  simulatie  applicaties  te  koppelen  (IEEE  standaard  1278.1). 
DIS  en  HLA  zijn  twee  verschillende  mechanismen:  DIS  is  een  simpele  data  distri¬ 
bute  architectuur,  gebaseerd  op  UDP/IP  broadcasting,  voor  berichten  met  een 
voorgedefinieerde  data  formaat  (PDU’s).  Dit  is  aan  de  ene  kant  een  voordeel 
omdat  het  network  protocol  gestandaardiseerd  is,  maar  aan  de  andere  kant  een 
nadeel  omdat  de  data  formaten  vastliggen  en  niet  flexibel  zijn.  HLA  daarentegen 
biedt  een  complex  distribute  mechanisme  en  laat  de  definite  van  syntax  en  se- 
mantiek  van  de  uit  te  wisselen  berichten  over  aan  de  federation  zelf  (FOM).  Dus 
meer  flexibiliteit  enerzijds,  maar  anderzijds  moeten  er  meer  afspraken  worden 
gemaakt  om  simulatie  applicaties  te  koppelen.  In  HLA  wordt  de  netwerk  perfor¬ 
mance  geoptimaliseerd  door  filtering  van  data  op  verschillende  niveaus 
(publication/subscripton,  DDM). 

Het  concept  van  de  Reference  FOM  probeert  de  voordelen  van  DIS  en  HLA  te 
combineren.  Een  Reference  FOM  is  een  soort  ‘basis’  FOM  voor  een  specifieke 
federation.  Een  Reference  FOM  bevat  object  en  interaction  class  definities  die 
veelvuldig  voorkomen  in  de  verschillende  federation  executions  van  deze  federati¬ 
on.  De  federation  executon  ontwikkelaar(s)  kan/kunnen  een  Reference  FOM  als 
basis  nemen  en  veranderingen  aanbrengen,  die  voor  zijn/hun  federation  execution 
specifiek  zijn.  Op  deze  manier  heeft  de  federation  toch  een  ‘standaard’  definitie 
voor  de  uit  te  wisselen  informatie,  met  de  flexibiliteit  om  specifieke  wensen  te 
implementeren.  Een  speciale  werkgroep  houdt  zich  op  dit  moment  bezig  met  het 
concept  Reference  FOM.  Er  wordt  gedacht  aan  verschillende  Classes  van  Referen¬ 
ce  FOM’s: 

Class  1 :  Community  Guidance  FOM 

Door  ten  minste  een  gebruikersgroep  ondersteund; 

Class  2:  Common  Denominator  (CD)  FOM 

In  ten  minste  een  programma/project  gedemonstreerd  en  waarvoor  een  of 
andere  vorm  van  stemming/accordering  is  uitgevoerd; 

Class  3:  Procurement  FOM 

Gebruikt  om  federates  bij  aanschaf  en  ontwikkeling  te  specificeren. 

Class  4:  Base  Object  Model 

Een  pakket  van  fundamentele  specificaties  die  gebruikt  kunnen  worden 
om  FOMs  te  construeren. 

Class  5:  Hierarchical  Object  Model 

Geordende  verzameling  van  fundamentele  specificaties. 
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Deze  verschillende  klassen  van  Reference  FOM’s  vereisen  ook  verschillende 
beheerprocedures.  Vooralsnog  is  de  discussie  over  het  concept  Reference  FOM 
niet  afgerond. 


De  Real’time  Platform-level  Reference  FOM  (RPR-FOM,  uitgesproken  als  ‘reaper 
fom’)  is  een  voorbeeld  van  een  Reference  FOM  die  de  inhoud  van  de  DIS  PDU’s 
beschrijft  in  de  vorm  van  een  robuuste  object  en  interaction  class  hierarchic,  De 
RPR-FOM  kan  als  basis  dienen  voor  (DIS-achtige)  real-time,  human-in-the-loop 
simulaties  van  fysieke  entiteiten  (zoals  tanks  en  vliegtuigen)  en  zal  een  belangrijk 
hulpmiddel  zijn  voor  de  migratie  van  DIS  naar  HLA.  Aangezien  het  concept 
Reference  FOM  nog  nader  onderzocht  moet  worden,  wordt  de  RPR-FOM  nog  niet 
als  HLA  data  standaard  erkend,  nog  afgezien  van  de  interim  versie  van  dit  mo¬ 
ment. 

In  het  vervolg  van  dit  hoofdstuk  bekijken  we  de  object  en  interaction  classes  van 
de  RPR-FOM  versie  0.1,7  in  meer  detail.  Bijlage  A  bevat  de  volledige  RPR-FOM. 


4.2  RPR-FOM  Object  Class  Structure 

De  RPR-FOM  object  classes  zijn  georganiseerd  in  een  4-niveau  diepe  hierarchic. 
Hike  subclass  erft  automatisch  alle  attributen  van  zijn  superclasses.  Dus  b.v.  Mill- 
taryEntity  heeft  alle  attributen  van  zowel  de  PhysicalEntityClass  als  de  BaseEntity 
class.  Een  subclass  is  een  specifiekere  vorm  van  de  superclass. 

Sommige  classes  hebben  geen  attributen  maar  zijn  toch  toegevoegd  met  het  oog  op 
Declaration  Management  (DM)  filtering  d.w.z.  filtering  op  basis  van  informatie 
type.  Voor  optimale  DM  filtering  moet  elke  federate  publications  op  ‘leaf-node’ 
niveau  doen  (d.w.z.  op  het  laagste  niveau  in  de  hierarchic)  en  subscriptions  op  een 
zo  laag  mogelijk  niveau  als  nodig.  Stel  federate  A  gaat  tanks  simuleren  in  de 
federation  en  publiceert  dus  de  class  Military LandPlarform.  Federate  B  is  gei'nte- 
resseerd  in  alle  militaire  voertuigen  en  abonneert  zich  op  de  MilitaryPlatformEn- 
tity  class  (subscription).  Federate  C  is  een  maritieme  applicatie  en  heeft  alleen 
belangstelling  voor  schepen  en  abonneert  zich  dus  op  de  class  MilitarySeaSurfa- 
cePlatform.  Attribute  updates  van  federate  A  zullen  dan  alleen  bij  federate  B 
aankomen,  en  voor  federate  C  eruit  gefilterd  worden.  Federate  B  ontvangt  alleen 
de  attributen  van  MilitaryPlatformEntity  en  zijn  superclasses,  want  de  binnenko- 
mende  MilitaryLandPlatfonn  instantie  wordt  automatisch  ‘gepromoveerd’  tot 
MilitaryPlatformEntity  omdat  daar  een  subscription  voor  is.  Wil  Federate  B  ook  de 
attributen  van  de  ‘leaf-node’  classes  ontvangen  dan  moet  hij  zich  op  de  individuele 
‘leaf-node’  classes  abonneren. 
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Base  Class 

BaseEntity 


EmbeddedSystcm 


EinittcrBcam 

SimulationManager 


Subclass 

PhysicalEntity 


2"“  Subclass  3^“  Subclass 

MilitaryEntity  MilitaryPlatform 

Entity 


AggregateEntity 

EnvironmentEntity 

Designator 

EmittcrSystem 

RadioReceiver 

Radio! ransmitter 

Track  JamBeani 


MunitionEntity 

Soldier 

CivilPIatformEntity  CivilAirLand 

Platform _ 

CivilAmphibious 

Platform _ 

CivilLand 

Platform _ 

CivilSpace 

Platform _ 

CivilSeaSurface 

Platform _ 

CivilSubmersiblc 

Platform _ 

CivilMultiDomain 

_ Platform _ 

Civilian 


4  Subclass 

MilitaryAirLand 

Platform _ 

MilitaryAmphibious 

Platform _ 

Military  Land 

Platform _ 

Military  Space 

Platform _ 

MilitarySeaSurface 

Platform _ 

MilitarySubmersible 

Platform _ 

MilitaryMulti 

DomainPlatform 


Figiiur  6:  RPR-FOM  Object  Class  Structure  Table 


De  RPR-FOM  specificeert  de  volgende  base  object  classes: 


•  BaseEntity 

De  BaseEntity  class  vertegenwoordigt  alle  fysieke  entiteiten  zowel  individueel 
als  geaggregeerd,  zoals  voertuigen,  personen  en  peletons.  De  class  bevat  attri- 
buten  die  betrekking  hebben  op  de  locatie  en  bewegingen  van  de  entiteit  in  de 
virtLiele  wereld,  zoals  positie,  orientatie,  snelheid  en  acceleratie. 
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•  EmbeddedSystem 

Deze  class  representeert  alle  fysieke  subsystemen  die  onderdeel  zijn  van  een 
entiteit,  maar  zich  zelf  niet  als  entiteit  in  de  federation  presenteren.  Voorbeel- 
den  van  de  EmbeddedSystem  class  zijn  radars,  radio  en  sensoren.  De  attributen 
van  deze  class  specificeren  de  relatie  met  de  entiteit  b.v.  de  entity  identificatie, 

•  EmitterBeam 

De  EmitterBeam  class  beschrijft  de  karakteristieken  van  een  emissie  zoals  b.v. 
scan  volume,  frequentie  en  vermogen. 

•  SimulationManager 

Deze  class  wordt  gebruikt  als  de  initiator  van  simulatie  management  berichten 
en  is  dus  geen  onderdeel  van  de  virtuele  wereld  zoals  de  bovenstaande  base 
classes.  Een  simulation  manager  federate  correspondeert  met  een  instantie  van 
de  class  SimulationManager,  De  enige  attribute  van  deze  class  is  een  string  die 
de  naam  van  de  simulation  manager  federate  identificeert. 

4.3  RPR-FOM  Interaction  Class  Structure 


Based  ass 

ActionRequest 

ActionResult 

AttributeChangeRequest 

AttributeChangeResult 

Collision 

CreateObjectRequest 

CreateObj  ec  tResu  1 1 

MunitionDetonation 

RadioSignal 

RemoveObjectRequest 

RemoveObjectResult 

WeaponFire 

Figiiur  7:  Interaction  Class  Structure  Table 

Interactions  bieden  een  mechanisme  voor  federates  om  discrete  events  te  versturen 
naar  andere  federates.  In  de  RPR-FOM  zijn  een  aantal  interactions  gespecificeerd 
voor: 

•  Simulatie  management  taken  (ActionReqiiest/Result,  AttributeChangeRe- 
quest/Result,  CreateObjectRequest/Result,  RemoveObjectRequest/Result) 


Botsingen  tussen  entiteiten  (Collision) 
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•  Munitie  interactie  (MunitionDetonation,  WeaponFire) 

•  Inter-object  communicatie  (RadioSignat) 

Zoals  Figuur  7  laat  zien,  heeft  de  huidige  class  structure  table  geen  hierarchie  en 
dus  alleen  maar  base  classes. 


4.4  RPR-FOM  Ontwikkelingen 

De  RPR-FOM  ontwikkeling  wordt  gedreven  door  een  werkgroep  welke  zijn  wor- 
tels  heeft  in  de  twee  laatste  DIS  Workshops  (mrt/sep  1996).  De  RPR-FOM  kent 
sinds  kort  ook  een  Versie  Plan. 

Versie  1  dient  alle  functionaliteit  te  bevatten  van  de  (DIS)  IEEE  1278.1-1995 
standaard.  In  Versie  2  zal  daaraan  de  functionaliteit  van  IEEE  1278.1  A- 1998 
toegevoegd  worden  (o.a.  Collisiofi’Elastic,  Underwater  Acoustics,  Intercom  Com¬ 
munication,  Entity  Management,  Minefield). 

Versie  3  wordt  genoemd  ‘Next  Generation  RPR-FOM\  Waarschijnlijk  wordt 
daarin  de  relatie  met  de  DIS-  IEEE  1278  standaarden  meer  losgelaten  en  de  moge- 
lijkheden  van  HLA  wat  dieper  geexploreerd. 

De  belangrijkste  discussiepunten  rond  Versie  1  zijn  nog  de  ‘vertaling’  van  de 
Radio  Signal  PDU  en  of  al  dan  niet  padding  fields  toegevoegd  moeten  worden  aan 
Complexe  Data  Types  (conform  DIS).  Ook  komen  er  vanuit  de  C3I-hoek  vragen 
om  meer  functionaliteit  dan  in  de  DIS-standaarden  is  gedefinieerd. 
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5.  Advanced  Simulation  Framework 

5.1  Electronic  Battlespace  Facility 

De  Electronic  Battlespace  Facility  (EBF)  is  een  TNO-FEL  infrastructuur,  bestaan- 
de  uit  hardware  en  software,  voor  onderzoek  naar  en  toepassing  van  gedistribueer- 
de  interactieve  simulatie  technologieen.  Er  is  gekozen  voor  een  flexibele  en  uit- 
breidbare  opzet  van  het  EBF,  zodat  ingesprongen  kan  worden  op  nieuwe  ontwik- 
kelingen  op  het  gebied  van  gedistribueerde  simulatie  (zoals  HLA)  en  herbruik- 
baarheid  van  beschikbare  componenten  (zowel  hardware  als  software)  maximaal 
is.  Het  Advanced  Simulation  Framework  ([ASF])  vormt  de  basis  software  laag  van 
de  EBF. 


5.2  ASF  Software  Architectuur 

Om  flexibiliteit  en  herbuikbaarheid  te  garanderen  is  gekozen  voor  een  object- 
georienteerde  aanpak  van  het  ASF.  Het  ASF  biedt  de  applicatie  toegang  tot  de 
virtuele  omgeving  aan  de  hand  van  een  gestandaardiseerd  interface.  Het  ASF 
schermt  de  applicatie  zo  veel  mogelijk  af  van  gedistribueerde  simulatie  standaar- 
den,  zoals  DIS  en  HLA,  Deze  opzet  vergemakkelijkt  migratie  naar  nieuwe  stan- 
daarden  omdat  de  applicatie  zelf  minimaal  veranderd  hoeft  te  worden.  In  principe 
zou  de  migratie  van  DIS  naar  HLA  door  een  hercompilatie  van  de  applicatie  gere- 
aliseerd  kunnen  worden,  mits  er  geen  DIS-specifieke  functionaliteit  in  de  applica¬ 
tie  zit.  Het  ASF  vormt  als  het  ware  een  tussenlaag  {'middleware  layer')  tussen  de 
applicatie  en  de  onderliggende  gedistribueerde  simulatie  standaarden. 

Figuur  8  illustreert  de  twee  iagen  van  het  ASF:  Environment  en  ObjectServer. 


Figuur  8  Advanced  Simulation  Framework  Software  Architectuur 

Environment  biedt  de  gebruiker  een  protocol-onafhankelijk  interface  tot  de  virtu¬ 
ele  omgeving,  m.a.w.  zonder  DIS-  of  HLA  specifieke  functionaliteit.  Via  Envi- 
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ronment  heeft  de  applicatie  toegang  tot  alle  simulation  objects  (b.v.  battlefield 
entities)  en  simulation  events  (b.v.  fire  en  detonation  events)  in  de  virtuele  omge- 
ving. 


ObjectServer  representeert  het  onderliggende  data  transport  mechanisme  dat  zorgt 
voor  de  uitwisseling  van  informatie  met  andere  applicaties.  ObjectServer  is  deels 
generiek  en  deels  protocol-specifiek:  voor  verschillende  gedistribueerde  simulatie 
standaarden  zijn  verschillende  ObjectServer  specialisaties  nodig,  afgeleid  van  de 
generieke  ObjectServer.  Figuur  8  toont  twee  ObjectServer  specialisaties  voor  DIS 
en  HLA.  Voor  de  DIS  variant  dient  de  commercieel  verkrijgbare  VR-LINK  Tool¬ 
kit  ([VRLINK])  als  communicatie  laag,  voor  de  HLA  variant  wordt  de  shareware 
DMSO  HLA/RTI  als  basis  gebruikt. 

De  object-georienteerde  methode  van  specialisatie  (ook  wel  subclassing  of  inhc’ 
ritance  genoemd)  wordt  gebruikt  voor  de  data  organisatie  van  simulation  objects 
en  simulation  events.  Figuur  9  toont  deze  data  structuur  in  de  Object  Modeling 
Technique  ([OMT])  notatie.  SimObject  bevat  functionaliteit  en  attributen  die 
generiek  zijn  voor  alle  simulation  objects  b.v.  object  ID.  Event  bevat  functionali¬ 
teit  en  attributen  gemeenschappelijk  voor  alle  events  zoals  sender  ID.  Beide  gene¬ 
rieke  classes  hebben  specialisaties  voor  zowel  DIS  als  HLA.  Op  deze  wijze  kan  de 
protocol-onafhankelijke  Environment  gebruik  maken  van  de  generieke  representa- 
ties  {Event  en  SimObject)  terwijl  ObjectServer  de  afgeleide  classes  (b.v.  DislEvent 
of  HlaObject)  kan  gebruiken  voor  protocol-specifieke  functionaliteit. 


Figuur  9  ASF  Data  Structures 

Het  ASF  is  beschikbaar  voor  zowel  Sun  als  SGI  computer  platformen. 


5.3  DIS2  ObjectServer 

De  DIS2  ObjectServer  stelt  de  gebruiker  in  staat  DIS  2.0.4-compliant  applicaties  te 
ontwikkelen.  Deze  implementatie  is  gebaseerd  op  COTS  software  van  Miik  Tech¬ 
nologies  Inc.,  namelijk  de  VR-LINK  Toolkit.  Op  dit  moment  wordt  binnen  het 
ASF  gewerkt  met  versie  2.4.3  en  2.4,6  van  de  toolkit,  VR-LINK  2.4.3  ondersteunt 
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DIS  versies  2.0.3  en  2.0.4.  VR-LINK  2.4.6  [VRLINK]ondersteunt  ook  de  officiele 
DIS-IEEE  1278.M995  standaard. 


54  HLA  ObjectServer 

De  huidige  HLA  ObjectServer  is  een  eerste  implementatie  van  een  RPR-FOM 
0.1.7-compliant  interface.  De  HLA  ObjectServer  maakt  gebruik  van  de  shareware 
RTI  1 .0.2  van  DMSO.  Het  doel  van  deze  ObjectServer  implementatie  was  aan  te 
tonen  dat  een  integratie  van  het  ASF  met  de  RTI  conceptueel  mogelijk  is  en  de 
gebruiker  in  staat  stelt  HLA  federates  te  ontwikkelen  op  basis  van  de  gestandaardi- 
seerde  ASF  Application  Programmer’s  Interface  (API),  dezelfde  interface  die  ook 
voor  de  ontwikkeling  van  DIS-applicaties  wordt  gebruikt. 

Omdat  niet  de  nadruk  is  gelegd  op  volledigheid  van  de  HLA  ObjectServer  maar 
meer  op  haalbaarheid  van  het  concept,  is  slechts  een  subset  van  de  RTI  services 
van  Interface  Specification  1.1  geintegreerd  in  het  ASF.  Ook  wordt  slechts  een 
subset  van  de  RPR-FOM  0.1.7  ondersteund.  Figuur  10  beschrijft  de  RTI  services 
die  thans  geintegreerd  zijn.  Van  Federation  Management,  Declaration  Manage¬ 
ment,  Object  Management  en  Time  Management  is  slechts  een  subset  van  de 
services  geintegreerd.  Ownership  Management  en  Data  Distribution  Management 
worden  nog  niet  ondersteund  door  het  ASF.  In  een  later  stadium  zullen  de  ontbre- 
kende  services  toegevoegd  worden. 


Interface  Specification  1.1  Service 

Service  Category 

Create  Federation  Execution 

Federation  Management 

Destroy  Federation  Execution 

Federation  Management 

Join  Federation  Execution 

Federation  Management 

Resign  Federation  Execution 

Federation  Management 

Publish  Object  Class 

Declaration  Management 

Publish  Interaction  Class 

Declaration  Management 

Subscribe  Object  Class  Attribute 

Declaration  Management 

Subscribe  Interaction  Class 

Declaration  Management 

Request  ID 

Object  Management 

Register  Object 

Object  Management 

Update  Attribute  Values 

Object  Management 

Discover  Object 

Object  Management 

Reflect  Attribute  Values 

Object  Management 

Send  Interaction 

Object  Management 

Receive  Interaction 

Object  Management 

Delete  Object 

Object  Management 

Remove  Object 

Object  Management 

Request  Federate  Time 

Time  Management 

Time  Advance  Request 

Time  Management 

Time  Advance  Grant 

Time  Management 

Figuur  10  RTI  Services  in  ASF 
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De  volgende  RPR-FOM  0.1.7  object  classes  zijn  deels  geimplementeerd  in  het 
ASF  voor  de  simulatie  van  battlespace  objecten  zoals  tanks,  vliegtuigen  en  militair 
personeel. 


Object  Class 

Super  Class 

Representatie  voor 

Base  Entity 

Alle  individuele  en  geaggregeerde  entiteiten 
zoals  voertuigen  en  personen,  De  class  bevat 
attributen  die  betrekking  hebben  op  de  locatle 
en  bewegingen  van  de  entiteit  in  de  virtuele 
wereld,  zoals  positie,  orientatie,  snelheid  en 
acceleratie. 

Physical  Entity 

BaseEntity 

Alle  individuele,  fysieke  platform  entiteiten  zoals 
militaire  en  civiele  voertuigen  en  personen.  De 
attributen  specificeren  de  karakteristieken  van 
het  platform  b.v.  welke  bewegende  delen  het 
platform  heeft. 

MilitaryEntIty 

Physical  Entity 

Alle  militaire,  individuele  platform  entiteiten 
zoals  tanks  en  militair  personeel.  De  attributen 
bepalen  karakteristieken  als  force  ID  en  ca¬ 
mouflage. 

Figuur  11  ASF  RPR-FOM  Object  Classes 

De  volgende  RPR-FOM  0.1.7  interaction  classes  zijn  deels  geimplementeerd  in  het 
ASF  voor  de  simulatie  van  munitie  lancering  en  detonatie. 


Object  Class 

Super  Class 

Representatie  voor 

Munition 

Detonation 

Detonatie  van  balllstische  of  geieide  munitie  in 
de  battlespace.  Parameters  specificeren  o.a. 
detonatie  locatle,  doel  en  type  munitie. 

WeaponFire 

Lancering  van  balllstische  of  geieide  munitie. 
Parameters  specificeren  o.a.  lanceer  positie, 
doel  en  type  munitie. 

Figuur  12  ASF  RPR-FOM  Interaction  Classes 

Een  verdere  beperking  van  de  huidige  HLA-variant  van  het  ASF  is  dat  er  nog  geen 
deadreckoning  is  geimplementeerd. 


5.5  Helicopter  Simulatie  Applicatie 

Het  ASF  wordt  reeds  in  een  aantal  simulator  prototypes  toegepast:  b.v.  Fennek 
Reconnaisance  Vehicle,  Leopard  2  A5,  F-16  en  Forward  Air  Controller  (FAC). 
Tevens  zijn  een  aantal  tools  op  het  ASF  ontwikkeld  zoals  een  scenario  manager  en 
een  tactical  display.  Reeds  is  aangetoond  dat  m.b.v.  ASF  vrij  eenvoudig  gedistri- 
bueerde  simulatie  applicaties  kunnen  worden  gebouwd  zonder  dat  de  applicatie 
boLiwer  veel  van  de  onderliggende  gedistribueerde  simulatie  standaard  hoeft  af  te 


weten 
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Om  de  migratie  mogelijkheden  van  DIS  naar  HLA  m.b.v.  het  ASF  te  onderzoeken, 
is  een  eenvoudige  helicopter  simulatie  applicatie  ontwikkeld.  Deze  applicatie  is  in 
staat  een  aantal  autonome  helicopter  platformen  te  simuleren.  Figuur  13  illustreert 
de  object-georienteerde  architectuur  van  een  helicopter  met  zijn  subsystemen. 


Figuur  13  Helicopter  Platform  Architectuur 

Elk  helicopter  platform  heeft  een  propulsion  system,  weapon  system,  radar  system 
en  een  combat  system.  Het  propulsion  system  zorgt  voor  de  voortstuwing  van  het 
platform.  Het  weapon  system  vertegenwoordigt  de  bewapening.  Het  radar  system 
is  een  sensor  waarmee  doelen  (andere  helicopters)  kunnen  worden  opgespoord.  De 
electronische  emissie  van  de  radar  is  niet  gesimuleerd,  Het  combat  system  is  een 
semi-intelligent  systeem  dat  de  volgende  taken  sequentieel  uitvoert: 

•  detecteer  doelen  m.b.v.  radar  systeem; 

•  selecteer  doel 

•  achtervolg  doel  totdat  platform  binnen  schietbereik  is; 

•  schiet  op  doel  totdat  doel  uitgeschakeld  is. 

De  helicopter  simulatie  applicatie  kan  op  een  willekeurig  aantal  computer  plat¬ 
forms  opgestart  worden.  Per  applicatie  kan  een  willekeurig  aantal  helicopters 
worden  gesimuleerd.  Het  ASF  zorgt  voor  de  uitwisseling  van  data  tussen  de  appli- 
caties  (locatie  gegevens  en  munitie  interactie). 

Voor  migratie  van  DIS  naar  HLA  van  deze  applicatie  was  slechts  een  hercompila- 
tie  nodig  van  de  applicatie.  Wijziging  van  de  source  code  was  niet  nodig.  Zowel  de 
DIS-variant  als  de  HLA- variant  bleken  te  draaien.  Er  was  een  verschil:  helicopters 
gesimuleerd  door  dezelfde  HLA  federate  (applicatie)  konden  elkaar  niet  uitscha- 
kelen.  De  reden  hiervoor  bleek  te  zijn  dat  interactions  verzonden  door  een  federa¬ 
te,  niet  door  dezelfde  federate  ontvangen  werden.  M.a.w.  de  detonations  interacti¬ 
ons,  die  communiceren  dat  een  helicopter  geraakt  is,  werden  niet  gedetecteerd 
door  dezelfde  federate  en  dus  niet  afgehandeld;  alleen  andere  federates  konden 
zijn  helicopters  uitschakelen.  Met  DIS  is  dit  probleem  er  niet  omdat  PDU’s  gebro- 
adcast  worden  en  door  de  zendende  applicatie  ook  zelf  weer  ontvangen  worden. 
Aangezien  deze  kwestie  (“moet  verzonden  informatie  door  de  zendende  federate 
zelf  gereflecteerd  worden?”)  nog  een  discussiepunt  is  binnen  de  HLA  community, 
is  er  voor  gekozen  dit  ‘probleem’  niet  in  het  ASF  op  te  lossen,  maar  het  resultaat 
van  deze  discussie  af  te  wachten. 


TNO-rapport 


FEL-98-A014 


27 


6.  Conclusies 


De  belangrijkste  conclusies  van  het  verrichte  onderzoek  zijn: 

•  De  ontwikkeling  van  de  High  Level  Architecture  draait  op  voile  toeren.  De 
architectuur  wordt  in  de  US  geaccepteerd  als  basis  voor  alle  simulatie-  en  mo- 
delleer-activiteiten. 

•  De  RPR-FOM  is  een  belangrijk  hulpmiddel  voor  de  migratie  van  DIS  naar 
HLA  voor  real-time,  human-in-the-loop  simulaties.  Dit  Object  Model  is  een 
voorstel  voor  een  data  standaard  die  de  informatie  uit  DIS  PDU’s  beschrijft  in 
de  vorm  van  HLA  object  en  interaction  classes. 

•  De  RTI  is  niet  veel  meer  dan  een  doorgeefluik  van  type-loze  federate  data.  De 
federate  is  zelf  verantwoordelijk  voor  de  opslag  van  deze  data  en  voor  de  con- 
versie  tussen  computer  platform  specifieke  data  en  de  netwerk  representatie 
van  de  data.  Veel  mensen  verwachten  veel  meer  functional iteit  in  de  RTI  ter 
ondersteuning  van  de  gebruiker. 

•  De  RTI  implementatie  van  DMSO  is  vrij  verkrijgbaar  en  biedt,  behalve  Data 
Distribution  Management,  alle  functionaliteit  uit  de  HLA  Interface  Specifica¬ 
tion  met  een  zeer  behoorlijke  performance.  Aangezien  de  source  code  niet  be- 
schikbaar  is  en  slechts  een  beperkt  aantal  computer  platformen  ondersteund 
worden,  heeft  de  toepasbaarheid  van  deze  RTI  implementatie  zijn  beperkingen. 

•  Het  ASF  biedt  een  vrij  eenvoudig  migratie  pad  voor  de  TNO  DIS-applicaties 
naar  HLA  via  een  'middleware  layer  approach.  Deze  software  laag  schermt 
de  applicatie  ontwikkelaar  af  van  de  onderliggende  gedistribueerde  simulatie 
standaarden  d.m.v.  een  generiek  interface.  Een  HLA-DIS  gateway  zou  een  an- 
dere  eenvoudige  oplossing  zijn  voor  een  migratie  van  DIS  naar  HLA:  de  gate¬ 
way  converteert  DIS  PDU’s  naar  RTI  calls  en  vice  versa.  Deze  aanpak  heeft 
echter  als  nadeel  dat  de  conversie  slag  de  latency  van  data  verhoogt  en  dat  de 
applicaties  nog  steeds  op  DIS  gebaseerd  zijn  en  dus  niet  de  voordelen  van 
HLA  gebruiken. 


Behalve  deze  conclusies  resulteerde  het  onderzoek  tot  een  aantal  bevindingen: 

•  Object  attributes  en  interactions  zijn  de  atomaire  eenheden  binnen  HLA  in 
tegenstelling  tot  DIS  waar  de  Protocol  Data  Unit  (PDU)  de  eenheid  is.  Na  ont- 
dekking  van  een  nieuw  object  binnen  de  federation  {discovery)  worden  niet 
automatisch  alle  object  attributes  aan  de  federation  bekend  gemaakt.  Een  fede¬ 
rate  kan  daardoor  een  onvolledig  beeld  hebben  van  het  object  b.v.  wel  de  posi- 
tie  maar  niet  de  orientatie.  De  federate  heeft  wel  de  mogelijkheid  om  de  ge- 
miste  attributen  op  te  vragen  om  zo  een  volledige  status  van  het  object  te  ver- 
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krijgen.  Een  3D  visual  heeft  b,v.  zowel  de  positie-  als  orientatie  data  nodig  om 
het  object  te  kunnen  visualiseren. 

•  HLA  staat  toe  dat  per  attribute  een  deadreckon  algorithme  gespecificeerd 
wordt  voor  de  extrapolatie  van  de  attribuut  vvaarde.  DIS  biedt  alleen  de  moge- 
lijkheid  voor  de  extrapolatie  van  positie-  en  orientatie  data. 

•  De  DMSO  RTI  maakt  gebruik  van  exception  handling.  Dit  is  een  mechanisme 
dat  de  applicatie  ontwikkelaar  in  staat  stelt  run-time  abnormaliteiten  af  te  van- 
gen  en  af  te  handelen.  Denk  b.v.  aan  een  division-by-zero  situatie.  C++  biedt 
een  uniforme  syntax  voor  exception  handling  a.h.v.  de  try,  throw  en  catch 
keywords.  De  gebruiker  heeft  de  mogelijkheid  dit  mechanisme  te  fine-tunen 
met  zelf-gegenereerde  exceptions.  Binnen  de  RTI  wordt  veel  gebruik  gemaakt 
van  exception  throwing  en  het  blijkt  een  zeer  nuttig  hulpmiddel  bij  de  ontwik- 
keling  van  HLA  federates.  De  programmeur  is  in  staat  exceptions  af  te  vangen 
om  de  abnormaliteit  te  herstellen,  zoniet  dan  termineert  de  federate  met  een 
duidelijke  melding  van  de  oorzaak.  B.v.  als  een  federate  zich  aanmeldt  bij  een 
federation  (‘Join’)  en  dit  mislukt,  dan  zal  de  RTI  een  exception  genereren.  De 
federate  kan  deze  exception  afvangen  en  b.v.  nog  een  poging  doen  zich  aan  te 
melden.  Als  de  federate  de  exception  niet  afvangt,  termineert  de  applicatie  met 
een  duidelijke  weergave  van  de  oorzaak. 

•  De  VR-LINK  3.0  Toolkit  van  Mak  Technologies  is  in  staat  applicaties  op  basis 
van  DIS  en  HLA  te  ontwikkelen.  Helaas  is  er  geen  backward-compatibility 
naar  oude  versies  doordat  de  VR-LINK  API  aanzienlijk  veranderd  is.  Tevens 
ondersteunt  VR-LINK  een  nu  al  verouderde  RPR-FOM.  De  toolkit  biedt  dus 
een  migratie  pad,  maar  met  de  volgende  nadelen:  licentiekosten,  weinig  flexi- 
biliteit  en  afhankelijkheid  van  Mak  m.b.t.  ondersteuning  van  nieuwe  RPR- 
FOM  releases.  Het  ASF  heeft  deze  nadelen  niet. 

•  Attribute  updates  en  interactions  worden  niet  gereflecteerd  door  de  federate 
die  de  data  heeft  gegenereerd.  B.v.  als  een  federate  de  ‘send  interaction’  servi¬ 
ce  aanroept,  zal  dat  niet  leiden  tot  een  ‘receive  interaction’  callback  binnen  de- 
zelfde  federate.  Dit  betekent  dat  als  een  federate  een  interaction  aan  een  be- 
paald  object  richt  (b.v.  een  munitie  detonatie  event  met  een  target  ID)  de  fede¬ 
rate  zich  er  terdege  van  bewust  moet  zijn  of  het  object  locaal  of  extern  gesi- 
muleerd  wordt.  Er  is  discussie  gaande  binnen  de  HLA  gemeenschap  of  reflec- 
tie  van  eigen  data  misschien  toch  gewenst  is. 

•  Datalogging  en  exercise  replay  in  HLA  is  verre  van  triviaal.  In  DIS  is  dit 
relatief  eenvoudig  omdat  DIS  gebaseerd  is  op  broadcasting  en  de  entity  heart¬ 
beat  een  continue  stroom  van  berichten  garandeert.  De  HLA  logger  moet  tij- 
dens  replay  rekening  houden  met  o.a.  routing  spaces,  subscriptions  van  andere 
federates  en  data  requests  van  andere  federates.  Ook  moet  de  HLA  logger  de 
transport  mode  (best-effort  versus  reliable)  en  de  ordering  mode  (receive-order 
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versus  timestamp-order)  van  de  gelogde  data  via  de  RTI  te  weten  komen  om  ze 
op  dezelfde  manier  te  kunnen  afspelen.  Dit  onderwerp  benodigt  nog  verder 
onderzoek. 

Voor  de  komende  periode  staan  o.a.  de  volgende  vervolgactiviteiten  op  het 

programma: 

•  Ervaring  opdoen  met  Object  Model  development  tools.  Deze  tools  ondersteu- 
nen  de  gebruiker  bij  het  opstellen  van  SOM’s  en  FOM’s. 

•  Performance  en  latency  metingen  van  de  RTI  en  het  ASF. 

•  Migratie  van  DIS  simulator  protoype  naar  HLA  a.h.v.  ASF. 

•  Uitbreiden  ASF  voor  wat  betreft  RTI  services  support  en  RPR-FOM  classes. 


Volgen  van  en  rapporteren  over  de  ontwikkelingen  op  het  gebied  van  HLA, 
RTI  en  RPR-FOM. 
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7.  Afkortingen 


ALSP 

API 

ASF 

CORBA 

COTS 

DDM 

DIS 

DMSO 

DoD 

EBF 

FED 

FOM 

HLA 

IEEE 

BP 

LAN 

MOM 

OMT 

PDU 

RID 

RPR-FOM 

RTI 

SISO 

SIW 

SOM 

TCP 

UDP 

WAN 


Aggregate  Level  Simulation  Protocol 
Application  Programmer’s  Interface 
Advanced  Simulation  Framework 
Common  Object  Request  Broker  Architecture 
Commercial  Of  The  Shelf 
Data  Distribution  Management 
Distributed  Interactive  Simulation 
Defense  Modeling  and  Simulation  Office  (US) 

Department  of  Defense  (US) 

Electronic  Battlespace  Facility 

Federation  Execution  Data 

Federation  Object  Model 

High  Level  Architecture 

Institute  of  Electrical  and  Electronics  Engineers 

Internet  Protocol  (RFC  791) 

Local  Area  Network 
Management  Object  Model 
Object  Modeling  Technique 
Protocol  Data  Unit 
RTI  Initialization  Data 

Real-time  Platform  level  Reference  Federation  Object  Model 
Run-Time  Infrastructure 

Simulation  Interoperability  Standards  Organization 
Simulation  Interoperability  Workshop 
Simulation  Object  Model 
Transmission  Control  Protocol  (RFC  793) 

User  Datagram  Protocol  (RFC  768) 

Wide  Area  Network 
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